Add Schedules.get_subscriptions_by_schedule to list a schedule's subscriptions - #1873

Motivation

Closes #1250. TSC wraps extract refresh tasks per schedule with get_extract_refresh_tasks(schedule_id), but there was no way to ask "which subscriptions run on this schedule?", which is what the issue asks for (monitoring the tasks in a schedule against a whitelist).

I went looking for a /schedules/{id}/subscriptions endpoint to mirror the extracts one, but the REST API doesn't have it. Subscriptions are only listable at the site level via Query Subscriptions, and each subscription already carries its schedule id. So this filters that list client side.

Behavior change

Adds one public method:

subs = server.schedules.get_subscriptions_by_schedule(schedule_id)  # -> list[SubscriptionItem]

It pages through the site subscriptions and returns the ones whose schedule_id matches, so on a busy site it costs one request per page. Nothing else changes. I put it on Schedules next to get_extract_refresh_tasks so the two task-listing calls live together. Because there's no server-side filter, this is a plain list, not a (list, PaginationItem) tuple like get(). Documented the per-page cost and the "no per-schedule endpoint" caveat in the docstring, and added a CHANGELOG entry.

Test plan

• test_get_subscriptions_by_schedule reuses the existing subscription_get.xml asset (its two subscriptions are on different schedules) and asserts only the matching one comes back.
• test_get_subscriptions_by_schedule_no_match asserts an unknown schedule id yields [].
• test_get_subscriptions_by_schedule_empty_id asserts an empty id raises ValueError, matching the other schedule methods.
• Full suite: 908 passed, 1 skipped. black --check and mypy clean.

One thing on trust rather than a regression test: I couldn't hit a live server, so the client-side-filter approach rests on the documented fact that Query Subscriptions returns every subscription with its <schedule id=...>, which the existing SubscriptionItem parsing already relies on.